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Ci Abstract 

^5 It seems to be generally accepted that designing correct and efficient concurrent software is 

■^ a sophisticated task that can only be held by experts. A crucial challenge then is to convert 

04 sequential code produced by a "mainstream" programmer into concurrent one. Various synchro- 

^^ nization techniques may be used for this, e.g., locks or transactional memory, but what does it 

r \ mean for the resulting concurrent implementation to be correct? And which synchronization 

A^ primitives provide more efficiency at the end? 

'"; In this paper, we introduce a correctness criterion for a concurrent "wrapper" of a sequential 

y^ program, i.e., a transformation that enables the use of a sequential data structure in a concurrent 

i_^ system. Informally, we require the resulting concurrent implementation to be locally sequential: 
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concurrent threads simply run the given sequential code and let the implementation worry about 
the potential conflicts. To make sense globally, the implementation should also be linearizahle 
with respect to the object type of the data structure. 
l/-^ We then evaluate the performance of different concurrent implementations in terms of the 

t" — sets of schedules (interleavings of steps of the sequential code) they accept. Intuitively, this 

\l captures the amount of concurrency that a given implementation can stand. This allowed us to 

(y~^ analyze relative power of seemingly incomparable synchronization techniques, such as various 

^^ forms of locking and transactional memory. 
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1 Introduction 



Implementing a correct and efficient data structure shared by multiple users is believed to be a 
Cd tedious and error-prone process. What if, instead, we use a concurrent "wrapper" of a sequential 

implementation of the data structure that allows every user to locally run its sequential code so 
that the resulting concurrent execution is globally correct. 

One way to do this is to use locks so that critical parts of a sequential program are only accessed 
in an exclusive mode. An implementation that grabs a lock on the whole data structure before 
executing a sequential operation imposes a serial order of operations but neglects the benefits 
provided by the multiprocessing power of modern machines. Efficient fine-grained locking requires 

'Part of this work was done when the author was with EPFL receiving funding from grant agreement N 248465, 
the S(o)OS project. 

^The research leading to these results has received funding from the European Union Seventh Framework Pro- 
gramme (FP7/2007-2013) under grant agreement N 238639, ITN project TRANSFORM. 



lots of intelligence, since it must be based on good understanding of which parts of the sequential 
code to protect at what time. 

A more automated approach is to use transactional memory (TM) and treat each (sequential) 
operation as a speculative transaction. If the transaction commits, the corresponding operation 
returns the response computed based on the state the transaction witnessed. If the transaction 
aborts, the operation does not take effect. This approach promises to make use of the hardware 
concurrency at low intellectual cost. But does this simplicity bring an efficiency degradation? 
Local serializability and LS-linearizability. We start with defining the very meaning of using a 
sequential data structure in a concurrent environment. One natural correctness requirement is that 
no thread ever reaches a state not anticipated by the sequential implementation. More precisely, 
we model an execution of a concurrent implementation as a sequence of invocations and responses 
of the high-level operations on the data structure (e.g.. Insert, Remove, or Contains calls on a 
set object), events of the corresponding sequential implementation (e.g., reads and writes to the 
items of a sorted linked- list used to implement a set), plus accesses to synchronization primitives 
(e.g., transaction delimiters or acquisitions and releases of locks). Now we say that an execution is 
locally serializable if the sequence of sequential events corresponding to each high-level operation 
is consistent with some sequential execution. The condition is weaker than serializability |19| 
since it allows sequential executions corresponding to different high-level operations to be mutually 
inconsistent. In particular, there may not exist a single sequential execution on the given data 
structure that is consistent with all local executions. But it is good enough as long as we only want 
our concurrent data structure to locally appear sequential. 

On the other hand, the implementation should "make sense" globally, given the type of our 
data structure. We require that the high-level history of every execution, i.e., the subsequence 
of high-level invocations and responses, is linearizable [3, 15 : each high-level operation should 



appear instantaneous at some point within its interval so that the high-level sequential semantics 
is respected. 

The combination of local serializability and linearizability gives a correctness criterion which 
we call LS-linearizability, where LS stands for "locally serializable." Note that we can easily think 
of implementations that are linearizable but not LS-linearizable (do not look sequential locally), 
as well as locally serializable but not linearizable (do not make sense globally). Therefore, the 
two properties indeed complement each other. We also show that LS-linearizability inherits one 



important property of linearizability [14,15 : it is compositional, a composition of LS-linearizable 
implementations is also LS-linearizable. 

For example, consider the set type implemented sequentially using a sorted linked list (cf. 
Algorithm IT] in Appendix IaI) . To check if the set contains a given value in a concurrent execution, 
we do not need to take a snapshot of the linked-list content. It is enough to make sure that each two 
consecutive elements of the list are read atomically. Indeed, the resulting LS-linearizable concurrent 
set implementation (described in detail in Appendix pi) only requires an operation to hold locks on 
two consecutive list elements at a time (so called hand- over-hand locking [4|[l4]). As a result, the 
Contains operation may run concurrently with multiple Insert {) operations, as long as they do 
not contend on the same consecutive pair of list elements. 

Relative concurrency. The sorted linked-list example above suggests that we can evaluate the 
performance of an implementation via the "amount of concurrency" it allows for. More precisely, 
we can associate the implementation with the set of schedules (interleavings of steps of the se- 
quential operations invoked by multiple users) it accepts, i.e., is able to process. Now we can 



compare different concurrent implementations (or implementation classes) for a given sequential 
data structure (or a class of data structures) based on the sets of accepted schedules. It is particu- 
larly intriguing to compare the concurrency properties provided by various classes of TMs against 
locking techniques. Indeed, a TM interacts with its user application through a fixed transactional 
interface {reads, writes, try Commit or tryAbort), and have no clue about the object's semantics, un- 
like lock-based implementations. On the other hand, TMs may "undo" their operations by aborting 
the corresponding transactions, which cannot be achieved with locks. The conditions under which 
a TM may (or have to) abort a transaction (e.g., captured via progress conditions |11| ) are of 
crucial importance here, since, intuitively, they allow the TM to distinguish correct (observed in 
LS-linearizable histories) schedules from incorrect ones. 

Results of concurrency analysis. We show first that fine-grained locking provides strictly more 
concurrency than a wide class of conflict-resolving TM-based implementations (resolving conflicts 
between concurrent transactions by forcefully aborting some of them) [12]. We describe a lock- 
based implementation that accepts every schedule with no conflicts, i.e., locking provides at least 
as much concurrency as conflict-resolving TMs. Moreover, we present a schedule that cannot 
be accepted by any strictly serializable TM (be it conflict-resolving or not), yet the schedule is 
accepted by a linked- list implementation using hand-over-hand locking plfMl. As a corollary, we 
derive that locking provides strictly more concurrency than conflict-resolving TMs. This is the 
price to pay for TMs being "oblivious" to the semantics of the object they implement, combined 
with the brute-force approach to conflict resolution. 

However, we show that the price is not inherent for TM implementations that enforce stronger 
progress conditions. The use of multi- version concurrency control allows implementing MV-permis- 
sive [20] strictly serializable TMs in which read-only transactions always commit. Surprisingly, TM 
implementations in this class accept schedules which cannot be accepted by any lock-based imple- 



mentation. Nevertheless, as handling multiple versions is known to come at a significant cost 20 
it is hard to translate such concurrency improvements to performance gains. In response to this, we 
extend our result to single-version strictly serializable TMs that abort read-only transactions only 
if they witnesses two or more concurrent updates. We conjecture further that TMs with relaxed 
consistency guarantees, such as elastic transactions [5|[9], may be used to match the performance 
of locks for a large class of search data structures (queues, hash tables or trees). 

At a large scale, we cannot definitively say that locks supersede transactions or vice versa. To 
determine the amount of concurrency provided by a synchronization technique, one should carefully 
specify its correctness and progress conditions, as well as on the type and sequential implementations 
of the given data structure. This paper gives a language in which relative concurrency of seemingly 
incomparable synchronization techniques can be properly analyzed. 

Roadmap. Section [2] gives basics of our system model. Section [3] introduces LS-linearizability 
and defines our concurrency relations. Section |4] presents a comparative concurrency analysis of 
lock-based implementations and TM-based ones. We conclude by discussing related work and open 
questions in Sections [5] and [6j Omitted proofs can be found in the optional appendix. 

2 Model 

In this section, we define what we mean by transforming a sequential type implementation into a 
concurrent one, and describe two synchronization techniques: locks and transactional memory. 



Sequential types and Implementations. An object type r is specified by the tuple ($, F, Q, qq, 5) 

where <1> is a set of operations, F is a set of responses, Q is a set of states, qo G Q is an initial state 
and JCQx^xQxFisa transition relation that determines, for each state, and each operation, 
the set of possible resulting states and produced responses. Hence, {q,TT,q',r) £ 6 implies that 
when an operation vr G $ is applied on an object of type r in state q, the object moves to state q' 
and returns a response r. We assume that 5 is total, i.e., for every g E Q, vr G $, there exist q' £ Q 
and r G F such that {q, vr, q' , r) G 5. We assume that every type r = ($, F, Q, qo, 6) is computable, 
i.e., there exists a Turing machine that, for each input {q,iT), q £ Q, n £ <1>, computes a pair {q' , r) 
such that {q, vr, q', r) G 6. Hence, we can construct a sequential implementation of type r as follows. 
For each operation tt, we define a deterministic procedure V^ that performs reads and writes on a 
collection of objects ^i, . . . ,Xm, m G N. The value returned by V^ is treated the response to n 
returned by the implemented object. 

Concurrent implementations. We focus on the problem of turning a given sequential implemen- 
tation Is of type r into a concurrent one, shared by n processes (users) pi, . . . ,pn (n G N). Each 
sequential procedure V^ is converted into a concurrent one by inserting synchronization constructs 
(such as locks or delimiters of software transactions) between reads and writes performed by V^ . 
Intuitively, the resulting concurrent implementation must locally (to each particular operation) 
look like the sequential implementation Is, while being globally correct with respect to r (a precise 
definition of our correctness criterion is given in Section ^ . 

Executions. An execution of a concurrent implementation is thus a sequence of invocations and 
responses of high-level operations, (atomic) read and write events and synchronization events (e.g., 
lock acquisitions and releases or transaction delimiters). We assume that executions are well- 
formed: no process invokes a new high-level operation before the previous one returns or takes 
steps outside its operation's interval. In this paper, we primarily focus on two synchronization 
techniques: locks and transactional memory (TM), described in detail below. 

Exported histories. Informally, a history exported by an execution E is the sequence of invoca- 
tions and responses of high-level operations and read- write events that take effect in E. The exact 
definition depends on the type of synchronization primitives used in the execution, and should 
be defined separately in each case (we define it for locks and TMs below). By convention, every 
execution of a sequential implementation Is is already a history. Histories H and H' are equivalent 
if, for every process pi, II\pi=H'\pi. 

A high-level history H of an execution E is the sequence of invocations and responses on high- 
level objects in E. A high-level operation vr precedes another high-level operation tt' in H, denoted 
TT -^p^ vr', if the response of vr occurs before the invocation of vr'. Two high-level operations are 
concurrent if neither precedes the other. A high-level history is sequential if it has no concurrent 
operations. H is complete if every invocation has a corresponding response. A history H is complete 
if the corresponding high-level history H is complete. 

A complete high-level history H is linearizable with respect to an object type r if it is possible 
to permute events in H to obtain a sequential high-level history S such that (1) -^jjQ^s and (2) 
5 is consistent with type r. Now an arbitrary history H is linearizable if it can be completed (by 
adding matching responses to a subset of incomplete operations in H and removing the rest) to a 
linearizable high-level history [3||15) . 

Locks. A lock provides exclusive access to an object X and is accessed through atomic operations 
acquire {X) {shared mode), acquire {X) {exclusive mode) and release(X). If no process holds the 



lock on some object X in shared or exclusive mode, then acquire^{X) returns true; if no process 
holds the lock on some object X in exclusive mode, then acquire {X) returns true. 

Given a sequential data structure, a corresponding concurrent lock-based one is obtained by 
inserting acquire and release events between the read-write events of each sequential operation. We 
assume a dynamic locking scheme: a process may only acquire a lock on X if X is the next object 
it is going to access. Also, a process releases all locks it acquired before returning the result of the 
operation. The history exported by an execution ii^ of a lock-based implementation is the sequence 
of events obtained from E by removing all synchronization (acquire/release) events. 

Transactional memory. A transactional memory {TM) provides access to a collection of shared 
objects (t-objects) via atomic transactions. A transaction T^ is a sequence of reads and writes 
on t-objects that begins with start-txn and ends with tryCommit or tryAbort, where tryCommit 
returns either commit (the transaction takes effect) or abort (the transaction does not take effect), 
and tryAbort aborts the transaction. Each transaction T^, and all its events are associated with a 
unique identifier k. Transactions Ti,Tj conflict in an execution ii^ on a t-object X if there exists 
a prefix of E in which Tj and Tj are incomplete and access X, and at least one of these accesses 
is a write. A transaction Tk is t-complete in E if it ends with tryCommit or tryAbort. We say 
that E is t-complete if it contains only t-complete transactions. For Ti.,Tfn in E, we say that T^ 
precedes T^ in the real-time order in E, if T^ is committed or aborted and the last event of Tk 
precedes the first event of T^ in E. Two transactions are concurrent if neither precedes the other. 
E is t-sequential if no two transactions are concurrent in E. We say that a t-complete t-sequential 
history E is legal if for every t-object X , every read of AT in i? returns the latest written value 
of X. Let E denotes the subsequence of E consisting of the events of commited transactions. A 
t-complete execution E is strictly serializable if there exists a legal complete t-sequential history S 
such that (1) E and S are equivalent and (2) S respects the real-time order of transactions. Now 
we say that a TM-based execution is strictly serializable if we can extend it to produce a t-complete 
strictly serializable execution. A TM implementation M is strictly serializable if every execution 
of M is strictly serializable. 

Note that we make a simplifying assumption that all TM operations appear atomic, which 
applies to most existing TMs. In terms of liveness, we assume that these operations are starvation- 
free: as long as every process is correct, every tm-operation eventually returns. In this paper, we 
primarily focus on strictly serializable TMs (formal definition in Appendix O. 

Given a sequential data structure, a corresponding TM-based concurrent one puts each sequen- 
tial operation within a transaction, i.e., every operation vr on it is implemented as: start-txn; V"; 
tryCommit, where V^ is the sequential implementation of vr. If tryCommit returns commit, then 
the result of V^ is returned to the user. The history exported by an execution £^ of a TM-based 
implementation is the subsequence of E obtained by removing all synchronization events and all 
events related to aborted or incomplete transactions. 

3 LS-linearizability 

Let H he a, history, and let vr be a high-level operation in H. Then ff|7r denotes the subsequence 
of H consisting of the events of vr. Let Ig be a sequential implementation of an object of type r. 

Definition 1 A history H is locally serializable with respect to Is if for all high-level operations 
TT in H, there exists S &T,, where S is the set of histories of Is, such that H\ir = S\tt. 



Note that local serializability stipulates that the execution is witnessed sequential by every high- 
level operation in isolation. Two different operations (even when invoked by the same process) are 
not required to witness mutually consistent sequential executions. 

Definition 2 A history H is LS-linearizable with respect to {Is,t) if (1) H is locally serializable 
with respect to Is, and (2) the corresponding high-level history H is linearizable with respect to r. 



A correctness property is compositional 14,15 if, informally, a composition of correct object im- 



plementations is also correct. LS-linearizability is compositional (Appendix ??). It is not non- 



blocking 14, 15 , however, in the sense that an incomplete operation may not be able to complete 
on its own, which may be seen as a feature inherent to local serializability. 

We define the composition of two distinct object types ri and T2 as a type ri xr2 = ($, F, Q, qq, 5) 
as follows: $ = <I>i U <1>2, T = Ti U T2^ Q = Qi x Q2, qo = (goi, 902)) and ^CQx^xQxTis 
such that (((71, (?2)i TT, {Q1Q2)'''') £ i^ if and only ii n £ ^i {i = 1, 2) and {qi, vr, q[, r) S 5i. 

Every sequential implementation I5 of an object Oi x O2 of a composed type ti x T2 naturally 
induces two sequential implementations Isi and Is2 of objects Oi and O2, respectively. Now a 
correctness criterion ^ is compositional if for every history H on an object composition Oi x O2) if 
^ holds for H\Oi with respect to Isi, for i = 1,2, then ^ holds for H with respect to Is = I si ^ Is2- 
Here, H\Oi denotes the subsequence of H consisting of steps on Oj. 

Theorem 3 LS-linearizability is compositional. 

Proof. Let H, a history on Oi x02; be LS-linearizable with respect to I5. Let each H\Oi, i € {1, 2}, 
be LS-linearizable with respect to Isi- Without loss of generality, we assume that H is complete (if 
H is incomplete, we consider any completion of it containing LS-linearizable completions of II\Oi 
and H\Oi). 



Let H be the history of H. By the assumption, II\Oi and H 



O2 are linearizable with respect to 



Ti and T2, respectively. Since linearizability is compositional 14,15 , if is linearizable with respect 
to ri X r2. 

Now let, for each operation vr, S^ and S^ be any two sequential histories of /51 and I52 such 
that H\tt\Oj = Si\Tr, for j = 1,2 (since II\Oi and -ff|02 are LS-linearizable such histories exist). 
We construct a sequential history 3-,^ by interleaving events of S^. and 5^ so that S-n^lOj = Si, 
j G {1,2}. Since each 5^ acts on a distinct component Oj of OiX O2, every such S-j^ is a sequential 
history of Is- We pick one 5,^ that respect the local history II\it, which is possible, since II\tt is 
consistent with both 5i|7r and 52|vr. 

Thus, for each vr, we obtain a history of Is that agrees with H\7r. Moreover, the high-level 
history of H is linearizable. Thus, H is LS-linearizable. D 

It is easy to see that LS (locally serializable) linearizability is distinct from both serializabil- 
ity [19] and linearizability [iS]. For example, the classical queue implementation by Michael and 
Scott [IT] is linearizable, but allows threads to witness states that can only arise in concurrent 
executions (e.g., when underlying CAS operations fail). 

Also, consider the history of a sorted linked-list implementation depicted in Figure [2] Here we 
assume that the initial state of the set is {1, 3, 4, 5}, object Xj (i = 1, . . . , 6) is used for storing value 
i, and operation Containsi) returns true. The high-level history is linearizable with respect to the 



^Here we treat each Ti as a distinct type by adding index i to all elements of $i, Ti, and Qi. 



Integer Set type {Contains{) is linearized after the two Inserti) operations). But since Contains{) 
observes an old value of Xi (present before Insert{2)) and a new value of X5 (written by Insert{6)), 
and Insert{6) reads the value of Xi written by Insert{2), there is no way to find a global serialization 
for the three operations, i.e., the history is not serializable. But, as we show in Section |4j there 
exists an LS-linearizable Integer Set implementation based on hand-over-hand locking that exports 
this history. 

Preliminary observations. Two-phase locking {2PL) [23] is a lock-based implementation tech- 
nique in which every read of an object in the course of an operation involves acquiring a shared 
lock and every write involves acquiring an exclusive lock, and all acquired locks are released before 
returning the result of the operation. Thus, every sequential procedure of a sequential implementa- 
tion Is is converted into a concurrent one by inserting acquire {X) before read{X) and acquire {X) 
before write{X). The corresponding release events are inserted at the end of the procedure. Let 
/|^^ denote a concurrent implementation of a sequential data structure Is based on 2PL. Since 
2PL guarantees strict serializability [23] , we immediately obtain: 

Observation 4 For any sequential implementation Is of a type t, Is ^^ LS-linearizable with 
respect to (/s,r). 

Similarly, if we transform a sequential implementation Is of type r into a concurrent one using Ai, 
by treating every operation of / as a transaction, we obtain a strictly serializable and linearizable 
implementation /g , which implies: 

Observation 5 For any strictly serializable TM implementation A4, and any sequential imple- 
mentation Is of a type r, Ig^ is LS-linearizable with respect to {Is,t). 

Consider the sequential implementation LL of the Integer Set type (or set for brevity) described in 
Algorithm [1] in Appendix [Aj The type set maintains operations Insert, Remove and Contains with 
the usual semantics. We describe a concurrent implementation, I , derived from LL based on 
hand-over-hand locking |4j (HOH) (Algorithm [2] in Appendix pi). 

Theorem 6 I"^" is LS-linearizable with respect to {LL,set). 

3.1 Concurrency relations 

A schedule is an equivalence class of histories that agree on the order of events but possibly not on 
read values or high-level responses. Intuitively, a schedule describes the order in which high-level 
operations, and sequential reads and writes are invoked by the user. We say that an implementation 
/ accepts a schedule S if there exists an execution of / which exports a history exhibiting the order 
of S. Given a concurrent implementation /, let 5(1) denote the set of schedules accepted by /. 
Intuitively, S{I) reflects the "amount of concurrency" provided by /. 

A synchronization technique is a set of concurrent implementations. Given a sequential imple- 
mentation Is of an object type r and a synchronization technique A, let Ta{I,t) denote the set 
of LS-linearizable (with respect to {Is,t)) implementations in A. We say that a synchronization 
technique A provides less concurrency than a synchronization technique B with respect to {Is,t), 
and we write A ^(,^,,) B, iff VI G Ta{Is, r),3I' G Tb{Is, r), S{I) C S{I'). 

We say that A provides strictly less concurrency than B with respect to {Is,t), and we write 
A ^(,^,,) i3, iff {A ^(,5,,) B) A {B ^(,^,,) A). 

If A ^(/g^,-) B for all (Is,t), then we say that A provides less concurrency than B and write 
A^B. Similarly, we write A -i B, iff {A ^ B) A {B :^ A). 
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4 Locks vs. Transactional memory: Concurrency Analysis 

In this section, we use our concurrency relations to compare two synchronization techniques: locking 
(denoted C) and strictly serializable transactional memory (denoted M). We also consider three 
subclasses oi M: conflict-resolving implementations (CR), MV-permissive implementations (MP) 
and 1-progressive implementations (OP), and two subclasses of C: two-phase locking {2PL) and 
hand-over-hand locking {HOH). A summary of our results is presented in Figure [11 

4.1 Conflict-resolving TMs 

We say that an TM implementation is conflict-resolving if it exports no history in which two 
committed transactions experience a conflict. Intuitively, in conflict-resolving TMs, such as [12] , 
a transaction that witnesses a read-write conflict at some point during its execution is forcefully 
aborted or delayed. The class of implementations based on conflict-resolving TMs is denoted by 
CR. 2PL ensures that 

Theorem 7 CR < 2PL. 

Proof sketch. Let / G CR. Let schedule S be accepted by /, and let H be the corresponding his- 
tory be exported by I. Recall that H only contains events from committed transactions. Suppose, 
by contradiction, that S is not accepted by I^^^, i.e., some acquire^ or acquire^ invoked in H is 
unsuccessful. But then H has a prefix in which two high-level operations vr and vr' (1) are not com- 
plete and (2) both access the same object and at least one of these accesses is a write. Hence, the 
execution of / that exported H contains two conflicting committed transactions — a contradiction 
with the assumption that I E CR. Thus, 5(7) C S{2PL). D 



Now we show that there exist schedules that are accepted by some implementations in Tc{LL, set) 
(in our case /^*^^, the iJO// implementation of a linked list-based set) but not by any implementa- 
tion in Ttm{LL, set). Specifically, consider the schedule depicted in Figure [2l We observe that no 
two consecutive reads performed by the Contains (6) operation witness a conflicting write and, thus, 
I^o^ accepts the schedule. On the other hand, there is no way to serialize the three operations 
respecting the real-time order for Insert{2) and Insert{6) and making sure that the execution of 
Contains{6) appears sequential. Thus: 

Theorem 8 HOH :^(LL,set) M. 



Contains{6] I — • • • • • — I 
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Figure 2: A schedule Sq accepted by I"^" but rejected by / (we only show read- write events 
that matter); the initial state of the list is {1, 3, 4, 5} 
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Figure 3: An execution of I^^^ that accepts Sq; a^ , a^ denote lock acquisition in shared, exclusive 
modes, r denotes the release event. 

Proof. Consider processes pi, p2 and p^ that execute operations Contains{6), Insert{2) and 
Insert^G) respectively. We show that the schedule 5*0 in Figure [2| is accepted by I^^^ . Indeed, 
Figure [3| presents an execution of I^^^ that exports 5*0. It is easy to see that the acquire^ on 
Xi, X3, X4 is successful since there are no concurrent writes performed on these objects in this 
execution. It is thus enough to verify that pi does not hold the shared lock on Xi (resp., X5) at 
the moment p2 (resp., p^) tries to acquire an exclusive lock on it. Process p2 acquires the exclusive 
lock on Xi to insert 2 after pi has released the lock on Xi . Process pa invokes acquire on Xi , X2 , 
X3, X4 and returns successfully (since Insert{2) precedes Insert{6) in real-time) and finally invokes 
acquire on X5. Note that, at this point in the execution, pi does not hold the shared lock on 
X5. Hence, the acquire^ on X5 is successful. After the release of the lock on X^ by ps, process pi 
successfully acquires the shared lock on X^ and Xq. Since {1, 3, 4, 5} is the initial state of the list, 
Contains{6) is linearized after Insert{6) and returns true in H. 

Suppose now that Sq € S{I ), where M is a strictly serializable TM, and let H' be the 
corresponding history. Let transactions Ti, T2 and T3 encapsulate Contains{6), Insert{2) and 
Insert{6), respectively, in H' . Note that T2 must precede Ts in any serialization (real-time order). 
Since Ti reads Xi before T2 updates it, Ti must be serialized before T2. Thus, to produce a legal 
serialization of reads and writes, Ti must read the initial value of X5, where X^.next points to the 
tail of the list (according to our sequential implementation I5. 

But then, according to Is, Contains{6) cannot access Xq in H' , i.e., H' is not locally serializable 
(with respect to Contains{6)) — a contradiction. D 



Corollary 9 £ j< M. 

Theorem [7] and Corollary [9] imply: 
Corollary 10 CR -< C. 
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Figure 4: A schedule accepted by a MV-permissive TM implementation, but rejected by any lock- 
based implementation; the initial state of the list is {1,2,3} 

4.2 MV-permissive TMs 



An MV-permissive |20| TM allows a transaction to abort only if it is an updating transaction that 
conflicts with another updating transaction (In particular, no read-only transaction can abort). We 
denote by MP the class of implementations based on MV-permissive TMs. 

Consider the schedule of an implementation of {LL, set) depicted in Figure |4| It is easy to 
see that the schedule does not contain update-update conflicts, so an MV-permissive TM must 
accept the schedule (enforcing R{X2) and R{Xs) to return the initial values). The resulting history 
(assuming Contains{3) returns true) is linearizable and locally serializable with respect to {LL, set). 

In contrast, for any implementation in TciLL, set), R^X^) performed by Contains{3) must 
return the value written in VK(X3) performed by Remove{3) (otherwise the execution is not serial- 
izable). But W{X3) marks X3 as removed from the list, which can never be observed in a sequential 
execution of LL. Thus, the execution of Contains{3) is not locally serializable. 

Theorem 11 MP ^^LL,set) ^- 

Proof. Consider a implementation in Tc{LL, set) in which processes pi and p2 execute operations 
Contains{3) and Remove{3), respectively. Process p2 performs a write of X3 that marks the node 
to be removed from the list and then pi performs the read of node X3 (which has been deallocated 
from the list). But the history exported by any such execution is incorrect. Thus, there does not 
exist a lock-based implementation /^ such that {Si} G 5(/^). 

Let I denote a TM implementation that belongs to class MP. Let Ei denote an execution 
of/ in which transactions Ti, T2 encapsulate Contains{3) and Remove{3) respectively. Since Ti 
is read-only and T2 only conflicts with T2, both transactions must commit in Ei, and Ti, T2 is the 
only serialization (here R{X2 and R{X^) return the initial values in Ti). Also, the serialization is 
matched by a sequential execution of LL in which Contains{3) is followed by Remove(3). T\ms,I^^ 
is indeed an LS-linearizable implementation of {LL, set) that accepts Si. D 



Corollary 12 M :^ C. 

4.3 Single-version 1-progressive TMs 

Our reasoning around the schedule in Figure |4] assumed MV-permissive TMs that may have to 



maintain exponentially many versions of transactional objects 20 . We now describe an alternative 
progress condition, called 1-progressiveness, that allows for single-version implementations. We 
further show that OP, the class of implementations based on 1-progressive TMs, is not superseded 
by C, i.e., accept schedules that cannot be accepted by any lock-based implementation. 

Formally, a TM implementation is 1-progressive if (1) an updating transaction aborts only if 
it conflicts with another updating and (2) a read-only transaction aborts only if it conflicts with 
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Figure 5: Schedules ^i, 5^, 5*2, ^2, each schedule associated with its initial state 

another transaction over two or more t-objects. In Appendix [Cj we present a single-version 1- 
progressive serializable TM implementation. Note that since 1-progressiveness is strictly weaker 
than MV-permissiveness, this does not contradict the impossibility result in 120]. 



Consider schedules 5i and S[ depicted in Figures 5a and 5b In 5i, two concurrent processes 
pi and p2 perform Insert{2>) and Insert{2), respectively, and the initial state of the linked list is 
{1,4}, where 1 is stored in object Xi, 4 is stored in object X2 and the next field of Xi points to 
X2. S'l is similar to Si except that the initial state is {1,3,4} now, pi performs Remove{3), Xi 
stores 1 and X2 stores 3. We observe first that neither S'l nor S[ can be accepted by a lock-based 
implementation of {LL, set). 

Lemma 13 V/ G Tc{LL, set): Si S{I) and S[ ^ S{I). 

Proof. Suppose, by contradiction, that S'l is accepted by a lock-based LS-linearizable linked-list 
implementation /. Let E be the execution of I in which Si is exported. At the end of E, pi 
overwrites the next field of Xi that p2 had previously set to point to node X2 that stores value 2. 
Now Xi points to a new object that stores value 3 resulting in a "lost-update problem" . Indeed, 
consider an extension of E in which pi executes Contains{2) and returns. But, since the update ofp2 
has been overwritten by pi, the Contains operation may only return false. The resulting execution 
of / is not LS-linearizable (a previously inserted element 2 is not detected) — a contradiction. 

Similarly, suppose that S[ is accepted by some / and let E be the execution of I that exports 
S[. By the algorithm, pi writes to Xi making sure that the next field of Xi points to the object 
storing 4, and, thus, overwriting the update of p2- Again, a subsequent Contains {2) would return 
false, violating LS-linearizability. D 



Now consider schedules S2 and S2 depicted in Figures 5c and 5d S2 is like Si, except that the 
initial state now is {1, 3, 4} and, thus. Insert (3) performed by pi does not write to any object (the 
element is already in the set). Similarly, S2 is like S[, except that the initial state now is {1,4} 
and, thus, Remove{3) performed by pi does not write to any object (the element is not in the set). 
It is easy to see that both schedules correspond to LS-linearizable histories. Note that p2 is not 
able to distinguish executions exporting Si and S2: in both executions it reads values 1 in Xi and 
4 in X2. Similarly, p2 cannot distinguish executions exporting S'l and S2. We observe also that pi 
cannot distinguish Si and S2 {S[ and S2, respectively) up to the point when it executes R{X2). 
Therefore, intuitively, no lock-based implementation of {LL,set) can accept both S2 and S2. 

Lemma 14 VI e Tc{LL, set): {S2, S^} ^ S{I). 
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Proof. Let / be any lock-based LS-linearizable linked-list implementation and suppose that / 
accepts both 52 and 52- Let E and E' be the corresponding executions. We establish a contradiction 
by showing that / then also accepts Si or 5[ . 

Since, by Lemma 13, Si cannot be accepted, and p2 cannot distinguish S'2 and Si, pi must use 



a different locking scheme when executing Remove{3) and Insert{3). Li particular, in Insert{3) 
(schedules Si and S2), pi must grab a lock on Xi just before executing R{Xi). (Recall that we 
assume the dynamic locking scheme, so pi can only acquire a lock on Xi at this point.) 

But since S2 is accepted, p2 does not grab a conflicting lock on Xi before it distinguishes S2 
from Si (i.e., it has completed R{X2) and is about to execute W{X2)). Thus, in Si, pi must grab 
a conflicting lock on Xi just before executing W{Xi). Now we consider two cases: 

• In Si, p2 acquires a shared lock on Xi before executing I^(Xi). Thus, pi acquires an exclusive 
lock on Xi before R{Xi) in executing Insert{3) (in particular, in S2). 

Since S2 is accepted, p2 holds no lock on Xi in executing Insert{2) in E. But p2 cannot 
distinguish S2 and S[. Thus, in S[, p2 observes no conflicts while executing Insert{2) and 
completes the operation. On the other hand, when pi executes R{X2) and W{Xi), p2 has 
already terminated its operation and released all the locks. Thus, S^ is also accepted by I — a 
contradiction with Lemma I 



In Si (and, thus, in S2), P2 acquires an exclusive lock on Xi before executing W{Xi). 

Since S2 is accepted, pi acquires no locks before R{Xi) in S2. But pi cannot distinguish 
S2 and S[ before it executes R{X2)- Thus, in S[, p2 observes no conflicts while executing 
Insert{2) and completes the operation. On the other hand, when pi executes R{X2) and 
W{Xi), p2 has already terminated its operation and released all the locks. Thus, S( is also 



accepted by I — a contradiction with Lemma 13 



Thus, / does not accept one of the schedules in {S2, S2}. □ 

On the other hand, any implementation based on a 1-progressive TM (e.g., our single- version TM 
in Appendix O ensures: 

Lemma 15 V/ € Top{LL, set), {S2,S^} C S{I). 

Proof. Let E denote an execution of / in which transactions Ti and T2 encapsulate Insert{3) and 
Insert{2), respectively, interleaved as in schedule S2. T2 is an updating transaction that does not 
observe a conflict with another updating transaction in E. Also, Ti is a read-only transaction that 
is allowed to abort only when it conflicts with another transaction over at least two t-objects. Thus, 
by 1-progressiveness, both Ti and T2 must commit in E. 

The proof for Sg is analogous to the proof for S2. □ 



Lemmas 14 and 15 together with our implementation in Appendix [C] imply: 



Theorem 16 There exists I'-^^ G Top{LL, set) based on 1-progressive single-version TM that can- 
not be superseded by locks, i.e., for any I G Tc{LL, set), S{I^^) ^ S{I). 
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5 Related work 

Our correctness criterion (LS-linearizability) not only requires the high-level history to be lineariz- 
able, but also put restrictions on the base object accesses, as in strengthened versions of lineariz- 
ability (2|[7|, but differs in that it expects the execution to look sequential with respect to a given 
sequential implementation (local serializability) . In fact, local serializability can complement any 
of the restricted linearizability criteria in [21I7] . 

The idea of measuring the concurrency properties of LS-linearizable implementations via the 
set of accepted schedules generalizes the notion of the input acceptance metric proposed to compare 
specific classes of TMs flOj . Our concurrency metric, however, is not restricted to the TM context 
and can be applied to any synchronization technique. 

Empirical studies (6 |21|22| suggested that transactions can be as efficient as fine-grained locking. 
Our results exhibit a much more involved picture of relative concurrency properties of TMs and 
locks, where TM's progress conditions is an important factor. Conflict-resolving TMs are shown to 
be superseded by locks. On the other hand, MV-permissive and 1-progressive TMs accept schedules 
that cannot be accepted by any lock-based implementation. 

Locks and TMs were compared in the context of polymorphic and monomorphic transactions [8] , 
with respect to a single schedule of a specific implementation, making it difficult to draw general 
conclusions. In [9], the programming interface of locks was argued to provide more expressiveness 
than transactions in terms of programming ability. 

6 Concluding remarks 

In this paper, we focused on implementations that allow for running sequential code in concurrent 
environments. We defined what it means for such implementations to be correct via a combination of 
linearizability and local serializability. Then we analyzed relative amount of concurrency properties 
of LS-linearizable implementations using fine-grained locking and TMs (cf. Figure [T|. 

This work has two important implications. First, it gives a language to reason about the "best" 
synchronization techniques for a given data structure. Second, if we are restricted to use just 
one synchronization technique (e.g., transactional memory with specific consistency and progress 
guarantees), we can reason about suitability of a specific data structure. The analysis of the 
resulting concurrent implementation may give hints on how to adjust the data structure for better 
performance, e.g., by modifying its sequential implementation or object type. 

Many questions are yet to be resolved. The concurrency of the important class of relaxed trans- 
actional models should be better understood |l}[5| |13[[l8] . Relaxed TMs provide weaker consistency 
guarantees, compared to strict serializability and opacity, such as elastic opacity [5j. We conjecture 
that, for many important applications, such as search data structures, relaxed TM implementations 
may allow for strictly greater concurrency than locks. Our preliminary investigations indicate that 
the results in Section |4.3| can be extended to show that the linked-list implementation based on 
<f-STM ^1 (providing elastic opacity) accepts schedules that cannot be accepted by any lock-based 
implementations. Moreover, we conjecture that, at least with respect to {LL, set), f-STM allows 
for accepting all schedules accepted by HOH and, thus, possibly by any lock-based implementation. 

In the TM context, we only considered schedules triggered by committed transactions, which 
was enough for deriving concurrency lower bounds. One may argue that this is not sufficient if we 
want to prevent the user from ever observing an inconsistent state, even if its operation is not taking 
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effect, suggesting that strict serializability may not be an adequate TM consistency property. How 
the amount of concurrency is affected by extending local serializability to aborted transactions is 
unclear. 

One more important open question is how much the amount of concurrency tells us about the 
actual performance of an LS-linearizable implementation on a real multiprocessor machine with 
relaxed memory models, given the indications that high degrees of concurrency in software TMs 
may have a degrading effect on the resulting performance [16|. 
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A Sequential Implementation of Integer Set 



Algorithm 1 Sequential implementation LL [sorted linked list) of integer set type 



Shared variables: 

Nodes Head, Tail, X\, . . . 
Local variables: 

Boolean res, <r- false 

Locate (s): 

prev <— Head 

curr ■«— prev. next 

while (curr.val < s\J curr ■ 

prev <— curr 

curr <— curr. next 
end while 
return {prev, curr) 

Contains (s): 

{prev, curr) <— Locate(s) 
if curr.val = s then 

res <— true 
else 

res <— false 
return res 



Tail) do 



20 


Insert (s): 




21 


{prev, curr) <— Locate(s) 




22 


if curr.val / s then 




23 


Xs ^- new-node(s) 




24 


Xs.next ■(— curr 




25 


prev. next ■(— Xs 




26 


res -f- true 




27 


else 




28 


res <— false 




29 


return res 




30 


Remove (s): 




31 


{prev, curr) <— Locate(s) 




32 


if curr.val = s then 




33 


prev.next <— curr. next 




34 


free{curr) / / Deallocate 


node 


35 


res •<— true 




36 


else 




37 


res <— false 




38 


return res 





In this section, we recall the sequential specification of the integer set type (denoted set) and 
describe a sequential implementation using a sorted linked-list data structure. 

The type set is specified by the following operations: Insert, Remove and Contains. The 
sequential specification of set is as follows: Given an set S* C Z and an element s €z Z: 

• Insert(s) augments the set S with the element s ii s ^ S and returns true, otherwise S is 
unchanged and returns false 

• Remove(s) removes the element s from S* if s is not in S and returns true, otherwise S is 
unchanged and returns false 

• Contains (s) returns true if the element s is present in S, returns false otherwise 

The corresponding sequential implementation LL is presented in Algorithm[T] The implementation 
uses a sorted linked list data structure in which each node (except the Tail) maintains a next field 
to provide a pointer to the next node. 



B Hand-over-hand locking {HOH) 

In this section, we describe the implementation I^^^ (Algorithm 121) of an integer set type based on 
hand-over-hand locking 14]. In brief, HOH works as follows. Each object in the list is associated 
with a lock. Each node apart from the Tail contains a pointer next to a valid next node in the list 
when it is unlocked. An element is inserted into the list in the appropriate position while holding 
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the locks of the two adjacent nodes. The Remove node method redh'ects the predecessor's next 
field to make the node unreachable to other processes and then deallocates the node. 

Theorem 17 (Theorem [6]) I^'^^ is LS-linearizable with respect to {LL,set). 

Proof. Let E denote an execution of I^'^^ and H, the corresponding history. Let <e denote an 
total-order on events in E and H denote the high-level history of H. The linearization point of an 
operation vr, denoted as ij^ is associated with an event performed during the lifetime of vr using the 
following procedure. First, we obtain a completion of H by completing every pending operation or 
discarding events from an operation as follows: 

• Every event from an incomplete Contains operation is discarded. 



Every event from an incomplete Insert operation that has not performed the action in Line 28 
of the Insert operation is discarded. 

Every event from an incomplete Remove operation that has not performed the action in 
Line [58] of the Remove operation is discarded from E; otherwise, it is completed with the step 
in Line 1591 



Next, we obtain a sequential high-level history S by associating linearization points with operations. 
For every operation tt, 1-,^ is defined as follows: 

• If vr is Contains, 1-,^ is associated with the successful acquisition of the lock for the last read 



on a node (excluding Tail) in Line 72 



If vr is Insert, ij^ is associated with Line 23 of the Insert operation. 



• If vr is Remove, (j^ is associated with Line 55 of the Remove operation. 

High-level Unearization. 

Lemma 18 //vtj — t-^ ttj, then vtj —7-5 ttj. 

Proof. It is easy to see that the real-time ordering of operations is respected in S since linearization 
points are chosen within the lifetime of the operation. D 



Lemma 19 S is consistent with the type integer set. 

Proof. If Contains(s) returns true in H, there exists Insert(s) that returns true in H such that 
Insert(s) — s-^ Contains{s). Then, Insert(s) -^s Contains{s) since iinsert{s) is associated with the 
acquisition of the exclusive lock on node (say) Xs and no other process can read Xg until the 
process executing Insert (s) releases Xg. 

Also, there exists no vr = Remove{s) that returns true in H such that Insert(s) -^s '^ ~^s 
Contains{s). Let processes pi and p2 execute operations vr and Insert(s) respectively. Suppose 
that such a vr exists. Then, ijnsert{s) <E ^n <e ^Contains{s)i Pi acquires the exclusive lock on node 
(say Xs) that contains the value s following which p2 attempts to read Xg. Process p2 can only read 
Xs after pi has released the lock on Xs ■ But prior to release of the lock on Xg , pi physically deletes 
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Xg from the list by redirecting the predecessor's next field to the node immediately succeeding Xg 



Thus, the check in Line 78 fails and Contains{s) must return false — contradiction. 

Now, if Contains(s) returns false in H, there does not exist Insert(s) that returns true such 
that Insert(s) -^s Contains{s) or there exists an Insert(s) that returns true and Remove(s) that 
returns true such that Insert(s) -^s Remove(s) — )-5 Contains{s). Again, the same arguments as 
above verify this claim. D 



From Lemmas 19 and 18, the proof follows. 

For the second part, we need to show that for all high-level operations tt in H, there exists a 
sequential history S of LL such that H\tt = S\tt. 

Consider any execution of Contains (s) by a process pi in I . Process pi cannot access a 
node deallocated from the list since the node and its predecessor are held exclusively by the process 
executing the Remove operation. Let Xg be the node that contains the value s. Suppose that pi 
acquires the lock on Xg in shared mode, then process pj executing Remove(s) cannot acquire the 
lock on Xg. Thus, Contains(s) precedes Remove(s) in the linearization. Otherwise if pj acquires 
the lock in exclusive mode on Xg prior to pi, then pi cannot read Xg until pj releases the lock 
on Xg and thus is linearized after Remove(s). In either case, the execution is consistent with the 
sequential execution of Contains (s). 

Let Pi be any process executing Insert(s) in I . Then, pi acquires the exclusive lock on node 
Xs_i (assuming the new node to be inserted is Xg). Thus, any other process that attempts to read 
Xs-i must observe the new element inserted and is linearized after the Insert(s). 

Let Pi be any process executing Remove(s) in I . Then, pi acquires the exclusive lock on 
node Xg and Xg^i. Consider any concurrent process pj that executes Contains(s), pj reads Xs_2 
and then attempts to acquire the lock on Xg^i, but Xs_i is locked by pi. Thus, pj waits until 
Pi releases the lock on X^-i and then proceeds to acquire the lock on it in shared mode. Thus, 
Remove(s) is linearized prior to Contains(s). Process pj traverses the entire list until it reaches the 
Tail and returns false. D 



C 1-progressive single-version TM implementation 

Algorithm [s] describes a 1-progressive TM implementation / . The implementation uses a wait- 
free multi-trylock object described in |16j . 

Let E be any execution of the TM implemented by Algorithm [3j We assume every t-object is 
initialized by some fictitious committed transaction Tq that precedes E. Let <e denote a total-order 
on events in E. 

For a transaction T^ that appears in E, the write set (resp., the read set) of a transaction T^, 
denoted Wset{Tk) (resp., Rset{Tk)), is the set of t-objects that are written (resp., read) in T^. 

Linearization points. Let H denote a linearization of E\tm constructed by selecting lineariza- 
tion points of tm-operations performed in E\tm- The linearization point of a tm-operation op, 
denoted as iop is associated with a base object event or a tm-event performed during the lifetime 
of op using the following procedure. 

First, we obtain a completion of E\tm by removing some pending invocations and adding 
responses to the remaining pending invocations involving a transaction T^ as follows: 
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Every incomplete readk, writek or tryA^ operation is removed from E\tm 



For every pending tryCj., if some base object Vj was written (Line 32), tryC^ is completed 



with the steps in 32 and 33 and the response Ck is added to the end of E\tm- Otherwise, 



Ak is added to the end of E\tm- 

Now a linearization H of E\tm is obtained by associating linearization points to tm-operations in 
the obtained completion of E\tm as follows: 

• For every tm-read opk, iopk is chosen as the event in Line [9] of Algorithm [3] 

• For every tm- write or tm-abort op^, iop^ is chosen as the invocation event of opk 

• For every opk = tryCk such that Wset{Tk) 7^ 0, £opk is associated with the successful release 



of the lock on Wset{Tk) (Line 33) 



For every op^ = tryCk such that Wset{Ti:) = 0, iopk is associated with the first step performed 
in Line I 



<H denotes a total-order on tm-operations in the history H. 

Serialization points. The serialization of a transaction Tj, denoted as 5t- is associated with the 
linearization point of a tm-operation performed within the lifetime of the transaction. 
We obtain a t-complete history H from H as follows: 

• For every transaction T^ in H that has not invoked tryC^., we insert tryCj^ ■ Aj. immediately 
after the last event of Tk in H 

• For every aborted transaction Tk in H, we remove all events associated with the transaction 
A serialization S is obtained by associating serialization points to transactions in H as follows: 

• For every updating transaction T^ , St^ is ^tryCk ■ 

• If Tk is a read-only transaction, then iop^ is associated with the linearization point of the first 
tm-read performed in Tk 

<S denotes a total-order on transactions in the t-sequential history S. 

Lemma 20 IfTi ^g Tj, then Ti <s Tj 

Proof. This follows from the fact that for a given transaction, its serialization point is chosen 
within the lifetime of the transaction implying if T -<fj Tj, then St^ <e ^t =^ Ti <s Tj D 



Lemma 21 S is legal 

Proof. Recall that S is legal if every tm-read of an object X performed by a transaction Tj returns 
the response of the latest value written to X in S. The latest value written to X in S is the value 
written by the last transaction Tj such that Tj <s Ti and X G Wset{Tj). 

To prove that 5 is legal, we need to show that if there exists a readj{X), X £ Rset{Tj)riW set{Ti) 
that returns the value of X updated in writei{X, value) (this is well-defined since every value written 
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to shared-memory by a transaction is associated with the unique identifier of the transaction), then 
there does not exist a transaction T^, X G Wset{Tk) such that Tj <$ Tk <s Tj. Suppose there 
exists no such Tk- We need to show that Tj <5' Tj. 
Consider two cases: 

(1) Suppose that Tj is a read-only transaction. Let readj{X') be the first tm-read performed by 
Tj. By assumption, St^ and 5Ti are iread{X') and itryd respectively. Since there exists no 
concurrent transaction that writes to some Xj G Rset{Tj), it is easy to see that Tj, Tj is a 
legal serialization. 

(2) Suppose that Tj is an updating transaction. Thus, 5tj and Jt^ are itryCj and itryd respec- 
tively. Thus, Tj, Tj is a legal serialization. 

Suppose such a Tk exists. Consider two cases: 

(2) Suppose that Tj is a read-only transaction. Assume the contrary that 

• there exists a readj{X), X G Rset{Tj) n Wset{Ti) that returns the value of X updated 
in writei{X, value) 

• 3Tk,Xe WsetiTk) such that Ti <s Tk <s Tj 

Since itryd ^e itryCk^ ^i releases the lock on X prior to the release of the lock on X by 
Tfc. Also, Tk can acquire the lock on X only after the release of the lock on X by Tj. By 
assumption, the release of the lock on X (and consequently the write of X to shared-memory) 
precedes the linearization of the tm-read of the first t-object X' G Rset{Tj) (Line^. But 
then readj{X) cannot return the value of X written by T — contradiction. 

(2) Suppose that Tj is an updating transaction. If there does not exist any Y G Rset{Tj) n 
Wset{Tk), Y ^ X such that readj{Y) returns the value of Y written by Tk, then Tj, Tj, Tk is 
a legal serialization. 

Suppose such a y G Rset(Tj) n Wset(Tk) exists. Assume the contrary that Tj <s Tk <s Tj. 
Consider the resulting ordering of events: Tj acquires the lock on X, writes to X, releases the 
lock on X, Tk acquires the lock on X and Y, writes to X, Y and releases the lock on them. 
Since readj{X) returns the value of X written by Tj, iread{x) precedes the release of the lock 



by Tk- Subsequently, Tj performs readjiY) and performs the check on Line 36 and proceeds 



to perform the check on Line 37 Since the timestamp of X has been updated by Tk since Tj 
last read it and Tk reads the value of Y written by Tk, Line 37 returns true and Tj returns 



Aj — contradiction. 



D 



From Lemmas 20 and 1211 we have 



Theorem 22 I^^ is strictly serializable. 
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Algorithm 2 Hand-over-hand locking implementation [sorted linked list) l^^H q£ ^^i^^g^j- g^f 


type 


1: 


Shared variables: 






66: 


Contains (s): 




2: 


Nodes Head, Tail, Xi,. . . 


35: 


Remove (s): 


67: 


prev •«— Head 








36: 


prev ■(— Head 


68: 


spinLock(pret;, S) 




3: 


Local variables: 


37: 


spinLock(prej;, 5") 


69: 


curr <~ prev.next 




4: 


Boolean result, £, <— false 


38: 


curr <— prev. next 


70: 


spmLock(cMrr, S) 








39: 


spinLock(cMrr, 5) 


71: 


while {curr.val < sV 




5: 


Insert (s): 


40: 


if curr.val > s then 


72: 


curr = Tail) do 




6: 


prev •«— Head 


41: 


spinLock(prev, E) 


73: 


release(pre?;) 




7: 


spinLock(pre?;, 5") 


42: 


spinLock(ci(rr, E) 


74: 


prev -f- curr 




8: 


curr -f- prev. next 


43: 


goto Line|57| 


75: 


curr <— curr.next 




9: 


spinLock(cttrr, S) 
if curr.val > s then 


44: 


else 


76: 


spinLock(curr, S) 




10: 


45: 


while {curr.val < (s — 1)V 


77: 


end while 




11: 


spinLock(prev, E) 


46: 


curr — Tail) do 


78: 


if curr.val = s then 




12: 


goto Line|25| 


47: 


release(pre?;) 


79: 


result <— true 




13: 


else 


48: 


prev ■(— curr 


80: 


else 




14: 


while {curr.val < {s — 1)V 


49: 


curr ■(— curr .next 


81: 


result <r- false 




15: 


curr — Tail) do 


50: 


spinLock(curr, S) 


82: 


release(pret;) 




16: 


release(prei;) 


51: 


end while 


83: 


release(c?trr) 




17: 


prev <— curr 


52: 


release(pre?;) 


84: 


return result 




18: 


curr -f- curr. next 


53: 


prev <— curr 








19: 


spinLock(cMrr, S) 


54: 


curr <— curr. next 


85: 


spinLock(X, mode): 




20: 


end while 


55: 


spinLock(cMrr, E) 


86: 


f^ false 




21: 


release(preT;) 


56: 


spinLock(pret;, E) 


87: 


while £ do 

£^acquire'"°'''=(X) 




22: 


prev •<— cwrr 


57: 


if curr.val = s then 


88: 




23: 


spinLock(pret;, _E) 


58: 


prev.next <— curr.next 


89: 


end while 




24: 


curr ■<— curr. next 


59: 


free(curr) 








25: 


if curr.val ^ s then 


60: 


result <— true 








26: 


Xs <— new-node(s) 


61: 


else 








27: 


Xs.next ■(— curr 


62: 


result <— false 








28: 


prev. next <— Xs 


63: 


release(pret;) 








29: 


resM^f •«— true 


64: 


release(cMrr) 








30: 


else 


65: 


return ok 








31: 


result -h- false 












32: 


release(pre?;) 












33: 


release(curr) 












34: 


return ok 













21 



Algorithm 3 /'-^^;Iinplementation of T^ executed by process pi 



Shared variables: 

clock G N, initially // Global clock 

Vj, for each t-object Xj 

Vj.ts, a timestamp for each object, initially 

Vj .tid, id of transaction that writes to Vj , initially To 

Vj.val, value of Vj 

L, multi-trylock object 

readk{Xj): 
ovj :— readivj) 
if Xj ^ Rset{Tk) then 

RsetiTk) ■- Rset{Tk) U {Xj} 
return ovj.val 

WTitek{Xj,v): 
nvj.val := v 
if Xj (jL 'Wset{Tk) then 

Wset{Tk) ■- Wset{Tk) U {X^} 
return ok 



18: tryAki): 
19: return Ak 



tryCki): 

if \Wset{Tk)\ =0 then 
if islnvalidl() then 

return At 
locked :— L.acquire{Wset{Tk)) 
if not locked then 

return At 
if islnvalid2() then 

L.release{Wset{Tk)) 

return At 
time:=clock() // Every t-object in Wset is assigned this timestamp 
for all Xj e Wset{Tk) do 

write{{vj.ts,Vj.tid, Vj.val}, {time, k,nvj.val}) 

L.release{Wset{Tk)) 
return Ck 

Function: islnvalidl(): 

if 3Xi G Rset{Tk):ovi.ts < Vi.ts then 

if 3Xj € Rset{Th):{vi.ts < ovj.ts) A {ovi.ts < ovj.ts) then 
return true 
return false 

Function: islnvalid2(): 

if 3Xj € Wset{Tk) : L.isContended{Xj) then 

return true 
if 3Xi e Rset{Tk):{oVi.ts < Vi.ts) then 

return true 
return false 
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